home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group98b.txt / 000091_icon-group-sender _Wed Jun 17 09:13:55 1998.msg < prev    next >
Internet Message Format  |  2000-09-20  |  4KB
  1. Return-Path: <icon-group-sender>
  2. Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239])
  3.     by baskerville.CS.Arizona.EDU (8.8.8/8.8.7) with SMTP id JAA10731
  4.     for <icon-group-addresses@baskerville.CS.Arizona.EDU>; Wed, 17 Jun 1998 09:13:51 -0700 (MST)
  5. Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM)
  6.     id AA21188; Wed, 17 Jun 1998 09:13:41 -0700
  7. From: gep2@computek.net
  8. Date: Tue, 16 Jun 1998 20:34:21 -0500
  9. Message-Id: <199806170134.UAA19159@axp.cmpu.net>
  10. Mime-Version: 1.0
  11. Content-Type: text/plain
  12. Content-Transfer-Encoding: 7bit
  13. Subject: Re: Directory access facilities
  14. To: icon-group@optima.CS.Arizona.EDU
  15. X-Mailer: SPRY Mail Version: 04.00.06.17
  16. Errors-To: icon-group-errors@optima.CS.Arizona.EDU
  17. Status: RO
  18. Content-Length: 3521
  19.  
  20. >>> My admittedly biased and possibly Unix-centric view: we don't need any
  21. >elaborate solutions, I think the idea of each read() returning one entry
  22. >from the directory is the best one. This finesses all the issues of quoting
  23. >blanks, quotes, wildchars etc. etc.
  24.  
  25.  
  26. >> "Finesses" -> "Ignores".
  27.  
  28. > But in this case, ignoring them is the Right Solution.
  29.  
  30. I suppose you're entitled to your opinion, but I certainly don't agree.
  31.  
  32. >>The problem (if you want something RELIABLE) with this kind of thing is
  33. that on multitasking systems (especially those crossing boundaries through a
  34. network) the entries can be changing (and entries even being added and deleted)
  35. WHILE you are retrieving your way through them.  It's much more robust to return 
  36. a snapshot, which at least _was_ valid and consistent at the time the
  37. snapshot was taken.
  38.  
  39. > It's not ANY more robust, since the underlying C calls (which the Icon
  40. runtime has to make in order to get the data) make no atomicity guarantees
  41. (on Unix, MacOS, etc.) when querying all the entries in a directory.
  42.  
  43. I don't argue that there might be bugs in the underlying calls, but the point is 
  44. that you're using those current bugs as an excuse to propagate those BY DESIGN 
  45. into the higher levels too.
  46.  
  47. It's entirely possible that one COULD fix the underlying problems... but it 
  48. wouldn't help if the higher levels were still inherently unsound.
  49.  
  50. >> It's entirely possible that (for example) the read(f) returns a temporary
  51. file name, which is no longer there by the time the stat() is issued for it.
  52.  
  53. > And how is this magically fixed?  
  54.  
  55. In this case, because you (presumably) wouldn't have to call STAT() at all.  
  56. Even if it DID fail after a call, you would probably need to deal with that 
  57. status differently than the "ambiguous failure" problem in the code's WHILE loop 
  58. as was listed
  59.  
  60. > This happens with the C API, which means that it will happen with the Icon 
  61. API.  Pretending it doesn't won't make the problem go away.
  62.  
  63. Again, it's one thing for there to be a bug in the underlying API.  It's another 
  64. thing entirely for that inherently poor design to propagate those faults to 
  65. higher level programs.
  66.  
  67. >>If stat() failed (e.g.) in such a case, then you'd terminate your while loop
  68. >prematurely.
  69.  
  70. >Which makes the code incorrect even with your solution, since the window of
  71. vunerability between the time you get the filename and the time you stat the
  72. file is still there.  
  73.  
  74. If you get a table with filenames and directories, then you don't have to STAT 
  75. yourself to find out whether you need to recurse or not.
  76.  
  77. > In either case, the code has to be modifed to something like
  78.  
  79. > every s := Files(sDirectory) do {
  80.     write(format(stat(s)))
  81. }
  82.  
  83. >> Like the old saying, it should be "as simple as possible... BUT NO
  84. SIMPLER."
  85.  
  86. > And the solution where we have a function that generates directory entries
  87. (and I don't believe we should overload read(), since this shares almost
  88. nothing in common with read()) is, IMHO, that solution.  
  89.  
  90. Again, you're entitled to your opinion.  But I still don't agree with you.
  91.  
  92. > What you are trying to graft onto it are atomicity guarantees, and that is 
  93. impossible since you need the underlying OS to make those guarantees.
  94.  
  95. It's not impossible that someday the underlying OS WILL make those guarantees.  
  96. If the supporting calls are such that they are still ineffective, then fixing it 
  97. in the OS doesn't solve anything.
  98.  
  99. Gordon Peterson
  100. http://www.computek.net/public/gep2/
  101. Support the Anti-SPAM Amendment!  Join at http://www.cauce.org/
  102.  
  103.